Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-041.txt

Text File | 1992-11-18 | 41.8 KB | 1,037 lines | [TEXT/MPS ]

C.S.M.P. Digest             Tue, 07 Apr 92       Volume 1 : Issue 41

Today's Topics:

    How to get suggestions to Symantec about the THINK products
    Animated cursors


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Phil Shapiro)
Subject: How to get suggestions to Symantec about the THINK products
Date: 2 Mar 92 20:20:39 GMT
Organization: Symantec Corp.

>>>>> On 29 Feb 92 21:06:09 GMT, [e-mail] (Jeffrey Verdegan) said:

 > Is there some other way to get their attention besides wasting lots
 > of bandwidth (like I'm doing =:-)) to send a whole boatload of
 > "yes" votes to the above suggestions?  On the other hand, I'm sure
 > there are other similar issues that will come up as a response to
 > this.

If you want to be sure to get your opinions heard, you may want to CC:
your thoughts to one of the official THINK support mailboxes. You
should either mail to AppleLink at [e-mail], or
CompuServe at [e-mail] .

    -phil
--
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]



---------------------------

From: [e-mail] (Anthony J. Patrinos)
Subject: Animated cursors
Date: 29 Jan 92 05:48:41 GMT
Organization: Syracuse University, Syracuse, NY


Does anybody know whre I can find info about dealing with animated curssors? I
could not find any significant help in Inside Mac or X-Ref. I guess the acur
resource comes ito play somehow, but I have no idea how.

Thanks in advance for your help.
Tony Patrinos
Syracuse University



- -------------------------

From: [e-mail] (geoff george)
Subject:  Animated cursors
Date: 29 Jan 92 12:56:02 GMT
Organization: Georgia Institute of Technology


I spent most of one day looking for Apple's recommended method of
animating cursors, since IM VI User Interface Guidelines say that
any decent app should at least use the spinning beach ball or
spinning watch. Nada. I found this very annoying - "You must do
so-and-so, but we won't tell you how, or support your doing so
in any way." No docs on the Finder's 'acur' (I think it is)
resources, although ResEdit knows about them.

Maybe this just has to do with the indices to IM and the various
manifestations of the TechNotes being poor.

Anyone got any pointers?

geoff
--
geoff george    [e-mail]        (my name)
        or    [e-mail]   (personal warmth from GaTech OCS)

"Ordinary f---ing people - I hate 'em. Ordinary person spends his life avoiding tense situations; repo man spends his life getting INTO tense situations."



- -------------------------

From: [e-mail] (Sylvia-Kay Isler)
Subject:  Animated cursors
Date: 29 Jan 92 23:10:40 GMT
Organization: University of Pennsylvania

Geoff George writes:
>I spent most of one day looking for Apple's recommended method of
>animating cursors, since IM VI User Interface Guidelines say that
>any decent app should at least use the spinning beach ball or
>spinning watch. Nada. I found this very annoying - "You must do
>so-and-so, but we won't tell you how, or support your doing so
>in any way." No docs on the Finder's 'acur' (I think it is)
>resources, although ResEdit knows about them.

>Maybe this just has to do with the indices to IM and the various
>manifestations of the TechNotes being poor.

>Anyone got any pointers?

CHECK OUT THE FOLLOWING:
Mactutor May 1989 pp 104 -110 "Lisa's Hourglass is Back!"
  This article describes 3 ways to animate hourglass and watch
  cursors with C code examples included.

Mactutor December 1988 pp 108
  A short description (with Pascal code) of how to animate a watch
  cursor.

Hope that helps.
Sylvia Isler
[e-mail]



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Animated cursors
Date: 30 Jan 92 22:35:27 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (geoff george) writes:
>
>I spent most of one day looking for Apple's recommended method of
>animating cursors, since IM VI User Interface Guidelines say that
>any decent app should at least use the spinning beach ball or
>spinning watch. Nada. I found this very annoying - "You must do
>so-and-so, but we won't tell you how, or support your doing so
>in any way." No docs on the Finder's 'acur' (I think it is)
>resources, although ResEdit knows about them.
>
>Maybe this just has to do with the indices to IM and the various
>manifestations of the TechNotes being poor.
>
>Anyone got any pointers?

If you are using MPW, you can use the CursorCtl library that is
provided. The MPW documentation documents the calls in this library,
and describes how to use the 'acur' resource.

If you are using THINK whatever, I believe that you will have to write
your own animated cursor routines. In that case, the entry you want to
look up in Apple's documentation is SetCursor. There's no magic. Simply
call SetCursor with a different cursor at regular intervals.

(Side note: It really upsets me that people have to ask this question
all the time. First, it upsets me that people can't figure out on their
own how to spin a cursor. It's just not that hard. GetCursor,
SetCursor, repeat. What's so tough? Second, most people on this net use
THINK C or THINK Pascal, neither of which include the spinning cursor
libraries (someone please correct me if I'm wrong). Apple provides
Symantec with its headers and libraries. I assume that that includes
the CursorCtl library. If so, then shame on Symantec for not releasing it.
If not, then shame on Apple for not providing the library to Symantec, and
shame on Symantec for not providing a replacement library.)

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (P. Hawthorne)
Subject:  Animated cursors
Date: 31 Jan 92 06:42:39 GMT
Organization: Reed College, Portland OR


  [e-mail] (Keith Rollin) writes:
  Side note: It really upsets me that people have to ask this question
  all the time. First, it upsets me that people can't figure out on their
  own how to spin a cursor. It's just not that hard. GetCursor,
  SetCursor, repeat. What's so tough?

  Now, Keith, remember that there is a certain amount of dogmatism coming
from Apple about anything that involves the interface, much less anything
that involves using toolbox calls or affects the screen.
  Not that it took me more than half an hour to cope with animated cursors,
mind you, it's just that one ought to forgive caution on these issues.

  If it's really a hassle, roll it into the toolbox.
  Lest we forget, MPW and MacApp are not the toolbox and it is wrong for
Apple to assume that developers must have them. For those who do not have
those products, pointing out how they include solutions to problems is
rather like using a cruel inside joke.

  It seems almost, perish the thought, like something IBM would do.
Monolithic and impenetrable are phrases that I would imagine that Apple
as a whole should be avoiding like the plague.


  Q: What do you get when you cross Apple with IBM?
  A: IBM. -- from R.H.F.       Theus (orpheus@reed)



- -------------------------

From: [e-mail] (Eric E. Braun)
Subject:  Animated cursors
Date: 31 Jan 92 06:43:25 GMT
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158

>  [ Stuff about animating a cursor deleted]
>(Side note: It really upsets me that people have to ask this question
>all the time. First, it upsets me that people can't figure out on their
>own how to spin a cursor. It's just not that hard. GetCursor,
>SetCursor, repeat. What's so tough?

Ok, but lets say you want to spin a cursor so that it's always ultra
smooth, say from a time manager interrupt, now IM claims that
SetCursor doesn't move memory, but when you actually try this occasionally
you get a letftover cursor on the screen.



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Animated cursors
Date: 3 Feb 92 02:48:48 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Eric E. Braun) writes:
>>  [ Stuff about animating a cursor deleted]
>>(Side note: It really upsets me that people have to ask this question
>>all the time. First, it upsets me that people can't figure out on their
>>own how to spin a cursor. It's just not that hard. GetCursor,
>>SetCursor, repeat. What's so tough?
>
>Ok, but lets say you want to spin a cursor so that it's always ultra
>smooth, say from a time manager interrupt, now IM claims that
>SetCursor doesn't move memory, but when you actually try this occasionally
>you get a letftover cursor on the screen.

That's a different kettle of fish that dealing with calls that move
memory at interrupt time. When changing the cursor at interrupt time,
you have to make sure that QuickDraw isn't busy futzing with it. To
ensure this, check the semaphore 'crsrBusy', which is a byte in
low-memory. If it is zero, it's safe to change the cursor. I think the
sample code in the DTS Q&A stack shows how to do this.

None of this is relevent to the developer spinning the cursor in a
synchronous manner (i.e., by inserting calls to a SpinCursor routine at
regular intervals in her code).

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Animated cursors
Date: 1 Feb 92 23:27:20 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Anthony J. Patrinos) writes:
>
>
> Does anybody know whre I can find info about dealing with animated curssors? I
> could not find any significant help in Inside Mac or X-Ref. I guess the acur
> resource comes ito play somehow, but I have no idea how.

The Developer CD has sample code that shows how to create animated
cursors. Mark Johnson told me (Hi Mark, you're not here at the
office this Saturday?) that all the snippets and samples from the CD
are on ftp.apple.com, so check out for a folder/directory called
Animated cursors, should be inside the Development platforms folder/directory.

Kent Sandvik
- ----
no signature, man, this is out of this world...



- -------------------------

From: [e-mail] (Larry Rosenstein)
Subject:  Animated cursors
Date: 3 Feb 92 19:53:48 GMT
Organization: Object Based Systems, Apple Computer, Inc.

In article <[e-mail]> [e-mail] (Eric E. Braun) writes:
>
>Ok, but lets say you want to spin a cursor so that it's always ultra
>smooth, say from a time manager interrupt, now IM claims that
>SetCursor doesn't move memory, but when you actually try this occasionally
>you get a letftover cursor on the screen.

First, I don't know that you want to spin the cursor from an interrupt.  If
the idea is to show that the task is making progress, then it's wrong spin
the cursor if the program is really hung in a loop.  Instead, you should
spin the cursor as the program makes progress.

Second, if you do change the cursor from an interrupt then you are messing
with data structures that the system might be changing at the same time.  I
think there's a flag (CrsrBusy?) that indicates whether the cursor is
changing, and your routine has to check that and skip changing the cursor if
it is being changed already.

--
Larry Rosenstein, Apple Computer, Inc.

[e-mail]
(or AppleLink: Rosenstein1)



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  Animated cursors
Date: 3 Feb 92 21:17:20 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Eric E. Braun) writes:
> >  [ Stuff about animating a cursor deleted]
> >(Side note: It really upsets me that people have to ask this question
> >all the time. First, it upsets me that people can't figure out on their
> >own how to spin a cursor. It's just not that hard. GetCursor,
> >SetCursor, repeat. What's so tough?
> Ok, but lets say you want to spin a cursor so that it's always ultra
> smooth, say from a time manager interrupt, now IM claims that
> SetCursor doesn't move memory, but when you actually try this occasionally
> you get a letftover cursor on the screen.

This is true; if changing a cursor from a Time Manager task, you should
check to make sure that the low memory global CrsrBusy (a byte at location
8CD) is false.

However, I personally (and I am _not_ even remotely speaking from an Apple
perspective here) urge you to not change your cursor from a VBL or Time
Manager task without looking towards whether you're actually making progess.
More than a few times I've seen applications which would get hung in an
infinite loop, with the cursor merrily spinning away, totally uncoupled
from the application's actual state.  The purpose of spinning cursors is
(IMHO) to tell people that something is really going on; not to provide
entertainment for users forced to wait.  If you want to entertain your
users, make your program MultiFinder-friendly; that way we can all switch
out and play Spaceward Ho! while your program is mangling widgit figures.

Tim Dierks
MacDTS, but I speak for myself
First out, twice, Ho-Down '92



- -------------------------

From: [e-mail]
Subject:  Animated cursors
Date: 4 Feb 92 20:28:38 GMT
Organization: University of Otago, Dunedin, New Zealand


Speaking of animated cursors, is there (or should there be) a standard animated
cursor? I mean, we use the standard arrow/I-beam/watch cursors in the name of
consistency so that users feel comfortable with them, so is there any
documentation that says we ought to stick to either the animated watch or the
beachball? I raise this because I had what I thought was a rather cute rotating
bulldozer in UpdateMaker, but I struck a few people who were troubled by it
because they didn't recognise it.

Furthermore, on discussing this with colleagues the point was made that the
animated watch has somehow come to mean "I am waiting for something" whereas
the beachball means "I am doing Serious Processing" - but no-one was able to
say where this notion had come from.


Michael(tm) Hamel, Computing Services Centre, University of Otago, New Zealand

TOCKHOLES (pl. n.)
The tiny meaningless perforations which infest brogues.



- -------------------------

From: [e-mail] (Lloyd Lim)
Subject:  Animated cursors
Date: 4 Feb 92 00:19:30 GMT
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science

In article <[e-mail]> [e-mail] (Eric E. Braun) writes:
>>  [ Stuff about animating a cursor deleted]
>>(Side note: It really upsets me that people have to ask this question
>>all the time. First, it upsets me that people can't figure out on their
>>own how to spin a cursor. It's just not that hard. GetCursor,
>>SetCursor, repeat. What's so tough?
>
>Ok, but lets say you want to spin a cursor so that it's always ultra
>smooth, say from a time manager interrupt, now IM claims that
>SetCursor doesn't move memory, but when you actually try this occasionally
>you get a letftover cursor on the screen.

This is a bad thing to do.  Sure, it will look smoother but remember the
purpose of a busy cursor is to give feedback to the user.  If your program
locks up, the user will be able to tell that something is wrong because
the cursor hasn't spun in say five minutes.  If the cursor is too jerky,
then you probably aren't giving enough time to background tasks either.

You might want to spin a cursor smoothly for something else, like a game,
but the original thread was about normal busy cursors.

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Animated cursors
Date: 6 Feb 92 21:22:51 GMT
Organization: University of Waikato, Hamilton, New Zealand

There've been a number of people in this thread who've suggested that
animating a cursor from an interrupt routine is somehow not entirely
honest, since it doesn't guarantee that the code that is running is actually
making any progress.

I used to think this too, but now I'm not so sure. Consider this: a cursor
animation that is run by periodic calls from non-interrupt code still
doesn't guarantee that the code isn't stuck in an endless loop.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
Any opinions the author has expressed in this posting are sacred to
Epimetheus, the Greek god of hindsight.



- -------------------------

From: [e-mail] (Eye Care Centre)
Subject:  Animated cursors
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Date: Fri, 7 Feb 92 04:28:04 GMT

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>
>I used to think this too, but now I'm not so sure. Consider this: a cursor
>animation that is run by periodic calls from non-interrupt code still
>doesn't guarantee that the code isn't stuck in an endless loop.

I beg to differ. The spinning cursor is supposed to be a PPPI* and, as such,
is supposed to be indicating progress. Therefore, the watch should be spun
when progress is made which is different then spinning the cursor once through
a given loop. Therefore, if the cursor is spinning in an infinite loop, then
it is being spun on the wrong condition. (Note: There may be some examples
where it is not possible to think of a good condition upon which to spin the
cursor but I haven't come across any yet. This doesn't mean that there aren't
any.)

Bill Kiss
Dept. of Ophthalmology, UBC
- --------------------------------------
*PPPI - Poor Person's Progress Indicator



- -------------------------

From: [e-mail] (Benjamin T Sander)
Subject:  Animated cursors
Date: 9 Feb 92 05:21:38 GMT
Organization: University of Illinois at Urbana

Lawrence D'Oliveiro writes:

I used to think this too, but now I'm not so sure. Consider this: a cursor
animation that is run by periodic calls from non-interrupt code still
doesn't guarantee that the code isn't stuck in an endless loop.





See the "C Workshop" in the March 1991 Mac Tutor for the artical "Animated
Color Cursors", which discusses spinning the cursor with a VBL task that must
be refreshed by periodic calls from the main non-interrupt program.

I implemented something like this, but wasn't real happy with the results.
The smooth cursor made processing look too easy; somehow an erratically
spinning cursor gives the illusion that the machine is working so hard
doing important stuff that it doesn't have the time to mess with trivialities
like a spinning cursor.

Oh, well....


Ben Sander



- -------------------------

From: [e-mail] (Mark Lanett)
Subject:  Animated cursors
Date: 9 Feb 92 06:02:27 GMT
Organization: University of Illinois at Urbana

[e-mail] (Benjamin T Sander) writes:

>Lawrence D'Oliveiro writes:
>The smooth cursor made processing look too easy; somehow an erratically
>spinning cursor gives the illusion that the machine is working so hard
>doing important stuff that it doesn't have the time to mess with trivialities
>like a spinning cursor.

Yeah, right, try using MPW sometime. It spins the cursor so damn hard it looks
like it's doing *nothing but* spinning it. Reminds me of the ThinkC "why display
the numbers if it costing you so much time" question. I'd much rather it used
a VBL and counter than spin the stupid thing once every time through its loop.
--
Mark Lanett                                                   [e-mail]
Software Tools Group, NCSA, University of Illinois at Urbana-Champaign



- -------------------------

From: [e-mail] (Michael Kohne)
Subject:  Animated cursors
Date: 9 Feb 92 15:22:09 GMT
Organization: University of Maryland Baltimore Campus, Computer Science Department

In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>In article <[e-mail]> [e-mail] (Eric E. Braun) writes:
  [ Stuff about animating a cursor deleted]
>
>That's a different kettle of fish that dealing with calls that move
>memory at interrupt time. When changing the cursor at interrupt time,
>you have to make sure that QuickDraw isn't busy futzing with it. To
>ensure this, check the semaphore 'crsrBusy', which is a byte in
>low-memory. If it is zero, it's safe to change the cursor. I think the
>sample code in the DTS Q&A stack shows how to do this.
>
>None of this is relevent to the developer spinning the cursor in a
>synchronous manner (i.e., by inserting calls to a SpinCursor routine at
>regular intervals in her code).
>
>--
>------------------------------------------------------------------------------
>Keith Rollin           ---            <Taligent .signature under construction>
>Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...

You know, that's interesting. I've been having problems with ShieldCursor
and ShowCursor. I'm calling Shieldcursor from an interrupt routine, and I'm
getting cursor's 'left over' on the screen myself. Same problem,

--
"Pope" Q.E.D         Lord High Jabberwocky
Michael Kohne        [e-mail]
Coded Message: FIME NDUXXMS MZP FTQ EXUFTK FAHQE SKDQ MZP SUYNXQ UZ FTQ IMNQ.



- -------------------------

From: [e-mail] (James McCartney)
Subject:  Animated cursors
Date: 9 Feb 92 17:02:45 GMT
Organization: University of Texas, McDonald Observatory

In article <[e-mail]> [e-mail] (Mark Lanett) writes:
>[e-mail] (Benjamin T Sander) writes:
>>Lawrence D'Oliveiro writes:
>>The smooth cursor made processing look too easy; somehow an erratically
>>spinning cursor gives the illusion that the machine is working so hard
>>doing important stuff that it doesn't have the time to mess with trivialities
>>like a spinning cursor.
>Yeah, right, try using MPW sometime. It spins the cursor so damn hard it looks
>like it's doing *nothing but* spinning it. Reminds me of the ThinkC "why display
>the numbers if it costing you so much time" question. I'd much rather it used
>a VBL and counter than spin the stupid thing once every time through its loop.

    What I do in my spin cursor routine is to check TickCount and only spin
the cursor if a few ticks have passed since the last time. If it is time
to spin it I reset the time for the next spin. This way I get spinning
only if the program is actually doing something, but I don't get all the
cost of the SetCursor call each time and the cursor spins a a steady rate.
BTW: Using Ticks is faster than TickCount if you want to be evil and use a
low memory global.

   --- james mccartney
.
.  void *sig;
.



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Animated cursors
Organization: Kalamazoo College
Date: Mon, 10 Feb 1992 13:41:41 GMT

[e-mail] (James McCartney) writes:
>
>BTW: Using Ticks is faster than TickCount if you want to be evil and use a
>low memory global.
>

...and if you don't mind crashing on A/UX...
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Animated cursors
Date: 10 Feb 92 21:31:57 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Mark Lanett) writes:
>[e-mail] (Benjamin T Sander) writes:
>
>>Lawrence D'Oliveiro writes:
>>The smooth cursor made processing look too easy; somehow an erratically
>>spinning cursor gives the illusion that the machine is working so hard
>>doing important stuff that it doesn't have the time to mess with trivialities
>>like a spinning cursor.
>
>Yeah, right, try using MPW sometime. It spins the cursor so damn hard it looks
>like it's doing *nothing but* spinning it. Reminds me of the ThinkC "why display
>the numbers if it costing you so much time" question. I'd much rather it used
>a VBL and counter than spin the stupid thing once every time through its loop.

I don't think you should "much rather it" do that. Jebber (that's
American for "did you ever" for our international friends) wonder how
all your MPW tools magically got the ability to switch MPW 3.0 to the
background under MultiFinder?  It's because MPW puts a patch on
SetCursor that calls WaitNextEvent. This way, any tool that calls
SpinCursor or RotateCursor at regular intervals will allow MPW to be
switched into the background. This couldn't be done if the cursor were
spun at interrupt time.

It's this same patch that allows MPW 3.2 to update its windows and handle
mouse down and activate events while any generic tool is running, so
long as it calls SpinCursor or RotateCursor.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

Subject:  Animated cursors
From: [e-mail] (Bruce Hoult)
Date: Tue, 11 Feb 1992 08:59:05 GMT
Organization: Actrix Information Exchange, Wellington, New Zealand

[e-mail] (Lawrence D'Oliveiro) writes:

>I used to think this too, but now I'm not so sure. Consider this: a cursor
>animation that is run by periodic calls from non-interrupt code still
>doesn't guarantee that the code isn't stuck in an endless loop.

That's true, but such a problem is of a nature that is likely to be
discovered and fixed during testing.  A VBL-animated cursor is quite
--
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"



- -------------------------

From: [e-mail] (Kent Borg)
Subject:  Animated cursors
Date: 11 Feb 92 19:46:48 GMT
Organization: Camex Inc., Boston MA

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>There've been a number of people in this thread who've suggested that
>animating a cursor from an interrupt routine is somehow not entirely
>honest, since it doesn't guarantee that the code that is running is actually
>making any progress.
>
>I used to think this too, but now I'm not so sure. Consider this: a cursor
>animation that is run by periodic calls from non-interrupt code still
>doesn't guarantee that the code isn't stuck in an endless loop.


I want more than progress.  I would like to suggest that the animating
of a cursor not just tell me that the front app is happy and making
progress, but that the machine in general has not come to a hault.  I
like it when an animating cursor means that Get/WaitNextEvent is being
called.

So, yes, the front application might be stuck in an endless loop of
its own, but if Get/WaitNextEvent is being called then my download
hasn't crashed in the background, and I can switch to other
applications and save my work before I try to blow away the dead one
or just restart.

I say animate every several calls to GetNextEvent--and call
GetNextEvent frequently enough to be cooperative with the rest of the
machine.  (And certainly frequently enough to notice whether the user
has clicked your Cancel button--we all have one for long operations,
right?--or presses cmd-. --we do check for that, right?)


--
Kent Borg                            internet: [e-mail]   AOL: kent borg
                                            H:[phone]  W:[phone]
"Eating healthy beef is not healthful, the steer will take offense at you
chewing on his flanks."      -me



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Animated cursors
Date: 12 Feb 92 15:01:33 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail]
(Kent Borg) writes, in reply to my suggestion that animating a cursor
by periodic calls is no guarantee that the code isn't stuck in an endless
loop:

> I want more than progress.  I would like to suggest that the animating
> of a cursor not just tell me that the front app is happy and making
> progress, but that the machine in general has not come to a hault.  I
> like it when an animating cursor means that Get/WaitNextEvent is being
> called.
>
> So, yes, the front application might be stuck in an endless loop of
> its own, but if Get/WaitNextEvent is being called then my download
> hasn't crashed in the background, and I can switch to other
> applications and save my work before I try to blow away the dead one
> or just restart.

This is a good point that I admit I completely forgot about: calling
Get/WaitNextEvent periodically means that other processes continue to run,
regardless of whether you're making progress or not. And while you're
making such calls, this is as good a time as any to do cursor animation.

> I say animate every several calls to GetNextEvent--and call
> GetNextEvent frequently enough to be cooperative with the rest of the
> machine.  (And certainly frequently enough to notice whether the user
> has clicked your Cancel button--we all have one for long operations,
> right?--or presses cmd-. --we do check for that, right?)

I must admit I look on command-period as one of those slightly arcane
things that not every Mac user necessarily knows about. I prefer putting
up a dialog box with a "Stop" or "Cancel" button on it (whichever is
appropriate), that the user can click, and I don't bother checking for
command-period at all. Or command-full-stop, as some of us may prefer to call
it :-).

OK, now that we have a rationale for periodic Get/WaitNextEvent calls
that we can all agree on, how about some guidelines for actually doing it?

In a couple of the programs I've written, I have a sort of "usertask"
routine that gets called once around every loop. This usertask then
checks the value of TickCount against a previous call, and only spins
the cursor and calls Get/WaitNextEvent if at least 6 ticks (0.1 second)
have elapsed. This causes the cursor to spin smoothly, regardless of how
fast the loops are executing, while hopefully keeping to a minimum the
CPU overhead involved in doing so. And it's a good way to spot places
where I forgot to call my usertask, as when the program gets to such a
place, the cursor animation starts to become jerky.

I've found that clicking a "Stop" button and having it respond in a
maximum of 0.1 second seems pretty much instantaneous.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
"OS/2 is alive," claims Elvis fan.



- -------------------------

From: [e-mail] (Lloyd Lim)
Subject:  Animated cursors
Date: 13 Feb 92 00:01:53 GMT
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, [e-mail]
>(Kent Borg) writes, in reply to my suggestion that animating a cursor
>by periodic calls is no guarantee that the code isn't stuck in an endless
>loop:
>
>> I say animate every several calls to GetNextEvent--and call
>> GetNextEvent frequently enough to be cooperative with the rest of the
>> machine.  (And certainly frequently enough to notice whether the user
>> has clicked your Cancel button--we all have one for long operations,
>> right?--or presses cmd-. --we do check for that, right?)
>
>I must admit I look on command-period as one of those slightly arcane
>things that not every Mac user necessarily knows about. I prefer putting
>up a dialog box with a "Stop" or "Cancel" button on it (whichever is
>appropriate), that the user can click, and I don't bother checking for
>command-period at all. Or command-full-stop, as some of us may prefer to call
>it :-).

I tend to disagree.  True, a Stop or Cancel button is always best.  If you
have one, then you really should check for Command-period and Escape.
(And you should be checking for Command-period the right way, so it works
on international systems.)  The guidelines practically make this a law
for dialogs.  (Gee, sounds like I work for DTS.  :-)  :-(  )

Since most programs display a window that says something like "To cancel
printing, type Command-period (.)", I don't think it's that arcane.  Users
get the connection after a while, especially if it's in your documentation,
even more especially if it's in a list of shortcuts.  (Everyone loves
shortcuts; there's a great sense of satisfaction even if they don't save
that much work.  On the other hand, shortcuts are no excuse for a lousy
interface.)  Escape is somewhat natural to IBM converts.

>In a couple of the programs I've written, I have a sort of "usertask"
>routine that gets called once around every loop. This usertask then
>checks the value of TickCount against a previous call, and only spins
>the cursor and calls Get/WaitNextEvent if at least 6 ticks (0.1 second)
>have elapsed. This causes the cursor to spin smoothly, regardless of how
>fast the loops are executing, while hopefully keeping to a minimum the
>CPU overhead involved in doing so. And it's a good way to spot places
>where I forgot to call my usertask, as when the program gets to such a
>place, the cursor animation starts to become jerky.
>
>I've found that clicking a "Stop" button and having it respond in a
>maximum of 0.1 second seems pretty much instantaneous.

Your mileage will, of course, vary.  I find that 10 ticks for cursor spin,
15 ticks for WaitNextEvent, and 60 ticks for updating the numbers in the
status dialog are sufficient.  The response is good and I prefer to have
the machine look like it is really grinding away when it really is.

You're absolutely right in mentioning that the cursor spin is good feedback
for where to place calls.  Since it's tick-based, calling it too much
doesn't hurt, but not calling it enough is obvious in the cursor.  Yet
another reason not to use a VBL task...

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Animated cursors
Date: 30 Jan 92 22:35:27 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (geoff george) writes:
>
>I spent most of one day looking for Apple's recommended method of
>animating cursors, since IM VI User Interface Guidelines say that
>any decent app should at least use the spinning beach ball or
>spinning watch. Nada. I found this very annoying - "You must do
>so-and-so, but we won't tell you how, or support your doing so
>in any way." No docs on the Finder's 'acur' (I think it is)
>resources, although ResEdit knows about them.
>
>Maybe this just has to do with the indices to IM and the various
>manifestations of the TechNotes being poor.
>
>Anyone got any pointers?

If you are using MPW, you can use the CursorCtl library that is
provided. The MPW documentation documents the calls in this library,
and describes how to use the 'acur' resource.

If you are using THINK whatever, I believe that you will have to write
your own animated cursor routines. In that case, the entry you want to
look up in Apple's documentation is SetCursor. There's no magic. Simply
call SetCursor with a different cursor at regular intervals.

(Side note: It really upsets me that people have to ask this question
all the time. First, it upsets me that people can't figure out on their
own how to spin a cursor. It's just not that hard. GetCursor,
SetCursor, repeat. What's so tough? Second, most people on this net use
THINK C or THINK Pascal, neither of which include the spinning cursor
libraries (someone please correct me if I'm wrong). Apple provides
Symantec with its headers and libraries. I assume that that includes
the CursorCtl library. If so, then shame on Symantec for not releasing it.
If not, then shame on Apple for not providing the library to Symantec, and
shame on Symantec for not providing a replacement library.)

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Jeffrey Verdegan)
Subject:  Animated cursors
Date: 29 Feb 92 20:23:00 GMT
Organization: Computer Aided Engineering, Univ. of Wisconsin-Madison

In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>
>(Side note: It really upsets me that people have to ask this question
>all the time. First, it upsets me that people can't figure out on their
>own how to spin a cursor. It's just not that hard. GetCursor,
>SetCursor, repeat. What's so tough? Second, most people on this net use

To rise to the defense of those of us who asked the question, please, give us
some credit.  You're right, it's not that tough, and GetCursor, SetCursor, etc.
was how I was going to do it, when I remembered that there was an 'acur'
resource. "Hmmm.  Maybe 'acur' is 'animated cursor.'  Maybe there's a good
reason it's there, and I should do it that way.  There are warnings in Mac
programming books about not setting some things directly, but rather using the
routines provided.  Maybe this is one of those."  So, I posted to c.s.m.p to
find out how to get animated cursors using 'acur,' and found out that there
is no reasonable way in THINK (as you pointed out), at which point I decided
to just do it with Get and Set.

The point is, I *did* think of it, but I had good reason to believe there was
an "officially sanctioned and approved" way of doing it, and I'll bet some of
the others who posted the same question were thinking along the same lines.


Jeff


- --------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]



- -------------------------

From: [e-mail] (geoff george)
Date: 5 Mar 92 05:06:56 GMT
Organization: Georgia Institute of Technology

In article <[e-mail]> [e-mail]
(Jeffrey Verdegan) writes:
>In article <[e-mail]> [e-mail] (Keith Rollin) writes:

>>(Side note: It really upsets me that people have to ask this question
>>all the time. First, it upsets me that people can't figure out on their
>>own how to spin a cursor. It's just not that hard. GetCursor,
>>SetCursor, repeat. What's so tough? Second, most people on this net use

>... "Hmmm.  Maybe 'acur' is 'animated cursor.'  Maybe there's a good
>reason it's there, and I should do it that way.  There are warnings in Mac
>programming books about not setting some things directly, but rather using
>the routines provided.  Maybe this is one of those." ...

>The point is, I *did* think of it, but I had good reason to believe there was
>an "officially sanctioned and approved" way of doing it, and I'll bet some of
>the others who posted the same question were thinking along the same lines.

>Jeff



Yes, Jeff, that was exactly my line of reasoning when I posted the original
question that started off this thread. In my compulsive way, I was trying to
think of not _a_ way to do it, but _the best_, or at least an Apple-approved,
way to do it. The phrasing in IM VI certainly gave me the impression that
there was one of the last.

geoff
- --
geoff george    [e-mail]        (my name)
        or    [e-mail]   (personal warmth from GaTech OCS)

"Ordinary f---ing people - I hate 'em. Ordinary person spends his life avoiding tense situations; repo man spends his life getting INTO tense situations."

---------------------------

End of C.S.M.P. Digest
**********************